8.1 Quality Scenarios

Ar42 specifications helper

Contents

Concretization of (sometimes vague or implicit) quality requirements using (quality) scenarios.

These scenarios describe what should happen when a stimulus arrives at the system.

For architects, two kinds of scenarios are important:

• Usage scenarios (also called application scenarios or use case scenarios) describe the system’s runtime reaction to a certain stimulus. This also includes scenarios that describe the system’s efficiency or performance. Example: The system reacts to a user’s request within one second.

• Change scenarios describe a modification of the system or of its immediate environment. Example: Additional functionality is implemented or requirements for a quality attribute change.

Motivation

Scenarios make quality requirements concrete and allow to more easily measure or decide whether they are fulfilled.

Especially when you want to assess your architecture using methods like ATAM you need to describe your quality goals (from section 1.2) more precisely down to a level of scenarios that can be discussed and evaluated.

Form

Tabular or free form text.

ID	Quality attribute (ISO 25010)	Scenario type	Stimulus (source → event)	Environment / artefact	Response & measurable criterion
P-1	Time-behaviour / Responsiveness	Usage	User clicks Send RFQ at peak load (20 searches · s⁻¹ & 10 quote uploads · s⁻¹).	SPA + Spring REST	95 % of pages paint < 1 s; REST returns 200 in < 300 ms.
P-2	Throughput / Performance	Usage	Scheduler lists 1000 RFQs via /rfqs?limit=1000.	DB warm, 4 vCPU	Server completes in < 500 ms avg.
S-1	Confidentiality & Integrity	Usage	Un-authorised account reads another provider’s quote.	REST controller	Request refused HTTP 403, audit log entry in ≤ 200 ms.
S-1	Confidentiality & Integrity	Usage	Un-authorised account access provider evaluation.	REST controller	Request refused HTTP 403, audit log entry in ≤ 200 ms.
S-1	Confidentiality & Integrity	Usage	Un-authorised account access all the rfq	REST controller	Request refused HTTP 403, audit log entry in ≤ 200 ms.
S-3	Security – WS	Usage	Attacker subscribes to /topic/providers/XYZ without role.	STOMP gateway	Connection closed, no message delivered.
M-1	Modifiability	Change	PO adds TechSpec “Broadcast Standard” (ATSC, NTSC…).	Code repo	Domain model & UI shipped in < 5 person-days CI lead time; tests pass.
I-1	Interoperability	Usage	SAP Batch Job fetches 200 RFQs.	/openapi.json contract	Average latency < 200 ms; JSON conforms to schema v1.
I-2	Interoperability – discoverability	Change	Mobile-app team requests self links.	API v1.2	HAL links (_links.self) available for RFQ & Quote resources.
U-1	Usability – efficiency	Usage	RFQ manager uploads CSV (100 lines).	Browser	Items created in ≤ 2 min incl. validation errors.
R-1	Availability	Usage	Normal ops	Production cluster	≥ 99.5 % uptime per calendar month (≙ < 220 min downtime).